Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/972

Internet Message Format | 1994-08-27 | 10.6 KB

Date: Fri, 22 Jul 1994 13:46:57 -0400 (EDT)
Date: Fri, 22 Jul 94 01:28 EST
Subject: Gem List (Please Post!) (fwd)
Subject: Gem List (Please Post!)
Subject:  winlib...
Subject:  Re: Gem List (fwd)
Date: Fri, 22 Jul 1994 13:46:57 -0400 (EDT)
Mime-Version: 1.0
Precedence: bulk

Forwarded message:
>From [e-mail] Fri Jul 22 02:31:05 1994
Date: Fri, 22 Jul 94 01:28 EST
From: "Daniel J. Hollis" <[e-mail]>
To: ems <[e-mail]>
Subject: Gem List (Please Post!)
Message-Id: <33940722062833/[e-mail]>

Michael:
--------
> The reason I mentioned the keyboard is because the user will expect output
> to go to the top window when typing.  This has been a key aspect of
> GEM forever, and the user will expect it to hold true.  If there is
> not top window, or output goes to a window that is not topped, that
> is a confusing behaviour.  Perhaps XWindows handles this nicely, but
> it -started- that way.  Changing now would confuse the user
> needlessly.

What has this got to do with anything? WinLIB PRO always has the keyboard
focus on the topped window. To do otherwise is confusing. I don't know why
you brought this up, since WinLIB PRO doesn't do that.

> >GEM is not going to change to match my philosophy; so we're writing a
> >GEM Library to *match* the philosophy. There is no reason why users have
> >to be stuck in the dark ages in terms of a user interface.
> I'm not sure I understand your emphasis?  Match -what-?  The GEM
> philosophy (topped windows and all the other stuff you hate but is
> standard) or your own philosophy?  Coud you be more clear on this.

My philosophy : I want a *consistent*, *intuitive*, *easy to use*, *easy to
program* GUI that is powerful and fast. Currently GEM is *none* of these.

"Normal" GEM is inconsistent, non-intuitive, tricky to use, and more
difficult than it needs to be to program (AES 4.0 doesn't help anything).

WinLIB fixes all of these problems in one go.

Clear enough?

> > That is exactly the kind of thing I hate, auto-window-topping. If you had
> > actually read my message, you would have realized that.
> I did read your message, and I thought that this was a nice suggestion.
> If you do not want to top windows yourself, why not let the system do
> it so that you do not have to deal with it?  From the way you speak, this
> offends you to the core of your being...  :)

The problem here is that *I* want to be in control of the GUI, not let the
GUI control me. Therefore, I want to decide when windows get topped. And if
I want to access gadgets without having to top a window, I don't want to be
forced to use a *non-intuitive* method to access those gadgets (i.e. the
stupid left+right button combo).

> > It's confusing in that it's a non-consistent GUI design. There is no
> > reason why programmers have to be content with atari's stupid mistakes.
> There is one reason; the user expects it.  Small changes that improve the
> design are fine, of course, but major changes that shatter the old
> design are not fine.

It always makes me wonder why people are content living in the dark ages.

> > Other than the idiotic design in AES 4.x for hierarchical menus.
> I was talking about the menu layout, not the method of building a
> hierarchical menu.  I haven't honestly looked at that.

Look at it, and you'll find you will never look at AES 4.x quite the same
way again. :-)

> > We *did* do it right. If you had a copy of the demo program and used it,
> > you would never be able to tell that we do these so-called "time
> > wasting" things, unless we told you.
> Okay, Ken.  _Send_ me a copy, if you are willing, and I will look at it
> and summarize the experience to the list.  Does this sound fair?  I'll
> look at it objectively and tell you what I think.  This is about the
> tenth time you've said to someone that if they had only seen the
> demo copy they would be Might[ily] Impressed.  Well, if you were honestly
> offering, then send me a copy to [e-mail]
> and I will look at it and (maybe) be Might Impressed.

Actually, we *did* upload to the conference, but Yat declined to post it on
the basis that 'not everyone can use uudecode/unzip'. Shallow excuse
especially when other binaries have been posted to this conference in
exactly the same method.

I'm amazed at how much your attitude towards me has changed over the last
year.  Since we've not talked to each other since I sent you the last version
of WinLIB PRO, you've all-of-the-sudden got sour towards me.  Although I
don't take this personally, this is rather interesting when it comes toward
a person who was highly praising my library on ForemNET a year ago...  If
you keep talking down about it, why would you even WANT a copy of the
library?  I'll go ahead and send it to you anyway.

> > Wrong. Our library is much *smaller* than Gem++, yet has many more
> > features. The resulting executables that do the *same thing* as the
> > equivalent Gem++ program are generally several times *smaller*, not to
> > mention *faster*.
> GEM++ is a mega-library, though.  Of course it is big.  As for the size
> and speed, consider that you are using Pure C and GEM++ uses the
> monster-compiler C++.  How big is your library compared to EGEM, or
> SGEM, or ForceGEM?  Those are the biggest libraries I can think of
> for Pure C.  How does your library fit in with these?  (What is the
> actual SIZE of your library, for example?)

The size of WinLIB PRO (the old version) is 159,744 bytes (and this is
assuming that you will use *everything* in the library). WinLIB PRO
obviously strives for efficiency not simply in code size, but speed and
simplicity as well.

XAES (the reworked version of WinLIB PRO) is 238,592 bytes. Remember
of course that only the parts of the library that you use get linked into
your executable.

Tell me, where can I get SGEM, or ForceGEM?  What FTP sites, since I've never
heard of or seen these libraries.

> > Maybe you'll become confused by a straighforward GUI design, but I think
> > you'll be just about the only one. :-) Changing the mouse button
> > requirements for selection of a topped dialog and a background dialog are
> > totally against a sane GUI design. But then again, nobody ever claimed
> > atari is sane :-)
> Er, what?  I never said you should have to push a different button to use
> a background window.  I like the way Atari does it with MultiTOS, where
> you can use the left mouse button to operate the gadgets of a background
> window.

Notice the *key word* here. >>DIALOG<<, not >>WINDOW<<. So, it's o.k. to
operate background window gadgets with the left mouse button but it's not
o.k. to use the same button by itself for background dialog buttons? Talk
about inconsistent! :-)

>Yet you criticize us for improving on the wheel. Where do you draw the line?
> I draw the line at the point where you start changing the GUI so completely
> that a casual GEM-user would be confused by your changes.  Programs that
> are hard to learn do not get used, unless they are really, really great
> programs.

WinLIB PRO is easy to use, as the extended functionality is simply intuitive
extensions of what the user already knows. Unlike some of atari's
'extended features' which are decidedly non-intuitive. WinLIB strives to have
a CONSISTENT, INTUITIVE user interface, whereas 'other' people seem to strive
for exactly the opposite :-)

There are no major changes that would confuse the user, ie. with the custom
windows, the settings are the same (albeit there are other settings like
OPTIONS, ICONIFY, and CASCADE.)  There is nothing different about handling
the windows, just that you have to use my custom routines (WWindGet and
WWindSet.)  In the source I'm sending you, you'll see this.

> > WinLIB PRO was designed after intensive study of over *20* GUI libraries.
> > It incorporates the best ideas of all of them (we steal from the best, and
> > forget the rest :-) WinLIB PRO is extremely powerful, yet extremely
> > easy to use. WinLIB PRO does most of the work for you, with an extremely
> > straightforward, simple API.
> If you send a copy of the demo program to me, I'll be more than happy
> to take a look at it and report my findings to the list about whether or
> not you have the key to GUI perfection.  Mind you, if it crashes my
> system I'll mention that too.

Fine with me.  The last thing I need is a bashing about a library that has
not yet been released, and is not yet FIT to be released.

> "good", wouldn't you?  Oh, by the way, SozobonX apparently works with
> the Falcon. Pure C, on the other hand, does not.

Bzzt. Game over. Pure C works *FINE* with the Falcon. It always has. Pure C
1.1 even has bindings *FOR* the Falcon. Where did you ever get that bizarre
misconception that it didn't work on the Falcon? It isn't based on FIRST HAND
EXPERIENCE is it?

> I think that if people in this conference spoke more from EXPERIENCE and
> less from OPINION, we would be much more productive.
> I'm not sure I follow your comment.  My -experience- is that I do not know
> assembly language, and therefore have no real use for an assembly level
> debugger.  What on earth can you possibly object to in that?

I was applying it not only to assembler level debuggers, I was applying it
to this conference in general. I've noticed that people have been slinging
around comments about things (like the Pure C thing above) without having
EXPERIENCE. Just slinging stuff around based on OPINION and not EXPERIENCE
is a definite no-no.

> > (I could go into a discussion on memory fragmentation from alloc'ing and
> > free'ing memory for dynamically growing and shrinking a listbox, but I
> > digress...)
> You could, but why?  You could also mention that using Malloc() more than
> sixteen times on a TOS 1.0 machine will crash it.  Not an easy problem
> to get around.  None of this is on topic, though.

With PowerDOS this is not a problem. But I digress :-)

--Dan Hollis
----------
Subject:  winlib...

> some are talking about winlib as the best thing ever made on the atari. But
> is it possible to have a look at this? (demo versions, ...). Then we could
> say which library is the best for programmers and users. There are so many
> librairies available (wega, e_gem, gem++, sys_gem, magic, etc).

If Yat would actually POST the file we sent to the list... geez....  Where
can I get WEGA, or Sys_Gem?

--Dan Hollis
----------
Subject:  Re: Gem List (fwd)

Warwick:
> Are you talking about WinLIB PRO?  Ken once sent me a demo version.  It
> died a horrible death under my NOVA VDI.

What version of NOVA VDI were you using? Other people have used it on
NOVA cards (and various other video cards) with no problems. On the other
hand, old versions of the NOVA VDI drivers have numerous bugs.

--Dan Hollis
----------